Columbia Kermit/kermit.zip/newsgroups/misc.19950329-19950528/[e-mail]_Tue Apr 25 15:01:39 1995.msg

Internet Message Format | 2020-01-01 | 4KB

Received: from apakabar.cc.columbia.edu by watsun.cc.columbia.edu with SMTP id AA00927
  (5.65c+CU/IDA-1.4.4/HLK for <[e-mail]>); Wed, 26 Apr 1995 03:53:44 -0400
Received: by apakabar.cc.columbia.edu id AA07216
  (5.65c+CU/IDA-1.4.4/HLK for kermit.misc@watsun); Wed, 26 Apr 1995 03:53:40 -0400
Path: news.columbia.edu!panix!news.mathworks.com!gatech!swrinde!cs.utexas.edu!news.cs.utah.edu!cc.usu.edu!jrd
From: [e-mail] (Joe Doupnik)
Newsgroups: comp.protocols.kermit.misc
Subject: Re: File Corruption
Message-Id: <[e-mail]>
Date: 25 Apr 95 21:01:39 MDT
References: <[e-mail]>
Organization: Utah State University
Lines: 65
Apparently-To: [e-mail]

In article <[e-mail]>, [e-mail] (Glenn Herteg) writes:
> Can someone tell me what the chances are for file corruption in a
> Kermit transfer?  I always use Block Check 3, as I thought this was
> a near-perfect checksum.  But today I had a file corrupted during a
> transfer, in spite of that.  The relevant lines from the fullscreen
> display at the end of the transfer are:
>
> C-Kermit 5A(189), 30 June 93, play
>
>  Communication Speed: 19200
>               Parity: none
>
>            File Type: binary
>            File Size: 1448299
>         Window Slots: 1 of 30
>         Packet Count: 18054
>   Packet Retry Count: 3511
>   Packet Block Check: 3
>
>           Last Error: Timeout
>
> Once all the issues of flow control, timeouts, retries, etc. are
> past, that's when the checksum algorithm should get run.  There's
> clearly something complex about this file (it's compressed data)
> that causes the many retries, but I don't understand why the
> checksum algorithm is failing.  Is there a stronger alternative
> so I can get a better guarantee of correct transmission?  Do I
> have to run the UNIX "sum" after all transfers to make sure they
> got over the wire okay?
>
> Glenn Herteg
> [e-mail]
-------------
    Making the best I can of this...
    First of all, it appears as if the file tranfer terminated early
from a timeout. That would, naturally, lead to a "corrupted" file by missing
the end. Might this be the case here?
    Second, the above shows about one packet in six was repeated. That's
a fairly high error rate.
    Then, based on "second" we need to realize that no error checking
algorithm can be perfect. The block-3 check is a CRC polynomial method
and is as good as they get. But none is perfect. To entertain readers
with why I can say this comfortably may I receite a short story from
Andrew Tanenbaum's classical book "Computer Networks"? Ok, here goes.
    Two armies are fighting a final battle. One army is in a valley
and the other is split on two hilltops. The hill army can win if and only
if its two parts can attack in unison. Messages can be sent from hill to
hill, intercepted, faked, misunderstood, and all the foibles we can imagine.
The question is: is there an algorithm (messages) which guarantees absolutely
the hill army wins? Try it on the person sitting next to you on the plane.
    The answer is: there isn't such an algorithm. Each message needs
confirmation so that each side knows the other side knows what it does,
and knows that they know that it knows that they know, and so on. If a last
message gave that assurance, just supposing, and it happen to be lost then
things would go to pot. Thus, to be sure, we'd need confirmation that the
"last message" got through, consituting a "last message + 1" needing
confirmation, and hence the "last message" is not sufficient. The problem
recurses forever.
    The moral of the story is add as many check bits as desired, in
as clever a fashion as desired, and there still isn't a guarantee of
perfection. For a given check algorithm and fixed number of check bits
the chances of slipping through increase with the length of the packet.
    Maybe you can send a copy of the file to us at Columbia Univ for
replaying on local equipment.
    Joe D.